Randy: comments to be by Monday evening, or this gets sent at midnight.
Thanks for making the week bearable; without a point of sanity to
refer to, I would now be typing on a rubber keyboard.

Denny,

We believe that the future Tut-I's can be much improved by
the following actions and policies.  Priorities range from
1 (we won't do TUT-I without this) to 10 (a mild suggestion):

Perhaps the chief focus for the next TUT-I should be on the
Lab (MINIMA) for symbolic differentiation and integration.
Priority 1 item: The script handed out to the students is
indeed something they can get the program to do.  This has
two important criteria: there must be no bugs (unimplemented
features, rules that cause infinite loops, etc.), and the
program must run fast enough so that they can expect to get
through the script in the allotted time.  Each of these is
important.  If the program is bad, the system crowded, etc.,
then STILL we expect the handed-out script to be pared down
BEFORE HANDING IT OUT so that it meets both criteria.
One suggestion, if we are using a high-load-average machine
still next time, is to split the first lab session into
halves, on Tue and Wed afternoon, with half the class
coming in each day, and getting the other afternoon "off",
rather than all of them getting Wed. afternoon off.

Priority 2 item: one week before the TUT-I begins, i.e., on
a Monday, we hold a meeting with all the following people
present: Denny, Steve (and/or other Minima programmer(s)),
Doug, Rick, and Lee Hecht.  At that meeting, you (Denny)
present the script, run some of the program at a couple
archetypical points in that script, report on the total
CPU time it takes to do the script, the prevailing load
averages on the machine we're to use, etc.  If the
lab is not ready, or is too slow, etc., then at that
meeting we jointly arrive at a detailed plan for having
some acceptable recourse: changing the script, changing
machines, going back to the original MacLisp MINIMA,
eliminating the lab sessions entirely, hand-simulating them, etc.

Priority 3 item: the preferred way of ameliorating the lab
problems is to improve the program.  This means:
(i) speeding it up by AT LEAST a factor of 8; that would
make it about the speed at which the program ran last TUT-I.
An additional factor of 2-4 is only slightly less necessary.
(ii) adding the various features that were spec'ed out in the
script that we (Doug) provided you with: 
	How, Why, Better-rule, Common subexpression,
	Subproblem-of, Best/Depth/Breadth-first, Tutoring,
	Caching subproblems, Organizing the rules into a hierarchy,
	Transforming subproblem-reoccurennce into a linear
	equation so that integration by parts can work usually, etc.

Our strong opinion for speeding the program up is that
it be recoded in Interlisp directly, eliminating the
MRS mid-layer.  The precise types of pattern-matching
and indexing needed for the script can be done much
more quickly than the version we had last week.
Caching intermediate (sub-)problem results will also
help, as will compiling, of course.  MRS is an interesting
research vehicle, but using it for MINIMA is like using
a MAC truck to run down a mouse: it's more than we need
and it's SO much more that it actually makes things more 
difficult to hit that mouse.

Priority 3 item: not only should the lab be speeded up, it should
be more interesting and informative to watch.  We hope that
you will do the small amount (1-3 days) of coding necessary
for it to run on the Dolphins, with separate windows
dynamically displaying
	The body of rules (highlighting the one being used)
	The body of assertional facts, known subproblems, etc.
	The tree of subproblems (highlight the current one)
If you believe this would take more than 3 days to do, I
(Doug) will be happy to spend a couple days doing it.

We would need to have a total of about 20 Dolphin-hours set aside for
TUT-I that week, which should not be very painful as we can
schedule those hours months in advance.

Priority 4:  Given the "time off" periods (Tue and Wed afternoons,
Tue for half the class and Wed for the other half), we propose to
use them to provide an optional technical TEK pitch: the sort of
talks that Lee and Rick delivered on Friday: what exactly does
our company sell and do, who comprises it, what kinds of relationships
do we want to set up, etc.  Some students strongly want this, and
some strongly don't, so using the otherwise-time-off period for it
seems about right.

This about ends our comments on the Lab. Our next item is something
we have asked about since before the first TUT-I was given; it has
slowly risen in seriousness to its present Priority level of 2:
Priority 2: Reduce the variance in the background and intended goals
of the audience.  Some of these people are extremely well prepared
in AI, Lisp, expert systems, etc.; at the other extreme, many of
them come from classical DP backgrounds, with little motivation, 
litle willingness to open their minds and challenge their paradigms.
Some of the students will be expected to become KEs; some are managers;
some are scouts for their managers and must gather ammunition with
which to pitch a case to enter ESs and/or buy Lisp machines.
Their focus is: what's avaliable, what does it cost, who can use it,
how much manpower does it take, what are proven cases of cost-effectiveness,
etc.  To meet this problem, we propose that various flavors of TUT-I
be advertised and marketed, with specific audiences in mind:
	The manager or management scout
	The uninformed programmer
	The already-budding KE
Note that this is largely a marketing solution.  We will change our
offering to suit the various groups, but simply the act of separating
them is the most important action item.

Priority 2:  Given the strong interest in management and business
details even in the previous TUT-I, and anticipating a stronger
focus onthat in the Management-oriented future TUT-I's, we need
to get some hard data to present to them.  Lee, Rick, Jerry, and
others can help with this.  We need
	Case studies, with as much detail -- including dollar amounts
		and times -- as possible.
	Marketing studies
	Executive briefing materials (staffing a KE project, machines,...)
	Detailed specs on various Lisp machines, and on large
		machines which run various forms of Lisp.
	Samples of various Lisp environments.  This (and previous item)
		can probably be obtained from Fahlman and Steele at AAAI.
		They are giving a tutorial on Lisp environments just
		prior to AAAI; we should send someone to take it all down.
	Samples of running various extant ESs.  These samples can be
		hardcopy traces, living running programs, vidoetapes, etc.
	Sets of prepackaged alternatives for a company to adopt
		Dialect of Lisp
		Machine
		KE tools, languages, etc. for representationand control
		Mode of the project (e.g., collaboration, independent,...)
		Editor

Priority 6: Minor administrative problems and triumphs
This is a raft of observations on things that we noticed going
especially well or poorly at that level.
We were glad that we didn't have to clean up the room ourselves
this time.  The coffee was strong but always present.  The
morning food was good and always present.  The projectors were
there and set up when we needed them.  OK, so much for the plus side.
There was less communication (with us) than there could have been.
We were not told, e.g., that the TUT was being given in 525 Univ Ave
this time; who the attendees (and company affil and status) were;
how and where to park (incl: getting enough parking stickers
for us as well as for the students), why we were being videotaped,
why 3 man-months were spent making ugly TEX-ed versions of our slides,
why the MINIMA program was recoded into MRS-INTERLISP, etc. etc.
Beyond not telling us (which is more or less OK), there were some
problems with the administration:  the room is oddly shaped for
our purpose, quite noisy (kitchen noises), hot, and has no "second
door" to allow us an unintrusive entry/exit.  The slides were
not ready until almost literally the last minute, and as a result
there was a collection of problems in that area: some bugs on the
slides, some lines that were supposed to be hand-drawn not drawn,
many slides poorly laid out compared to the originals (TEX to blame,
but we could have told you that before you started -- that's
why WE don't use TEX to prepare slides), etc.  If asked, we would
have commented that an easy solution is to have photocopies made
of our slides, and have booklets pinted of photoreduced versions
from those.  That way, as our slides change from TUT to TUT, you
can adapt and modify your records.  We would be happy to supply you
with the slides we're going to use, in order, say 10 days prior
to the start of TUT-I each time.  We feel it's useful to have the
students' slide booklets conform exactly with the slides we actually
use on the screen.  That means TEX is out, and updating is crucial.
Badges: we liked the old style, with name and Company name on them;
this time the Company name was omitted.  Also, having ribbons
hang down saying "Speaker" and "Director" were real tacky.
Introductions: Doug&Randy usually introduce each other.  Even
after explicitly requesting such
intros, we were not introduced except facetiously.  Several
students asked us during the week who exactly we were, where
we went to school, etc.  So much for introducing US.  We
have found that the time right after lunch on day 1 is ideal
for having students introduce themselves, company, interest in ES, etc.
This takes a few minutes per student and is of great use both to
us in adjusting our talks and to the students in breaking the
ice, etc.  An abortive 5-second per person version of this was
done at the very beginning of the TUT, when students wanted to
listen rather than talk, and when they certainly weren't ready
to talk about themselves to each other; that also made it seem
silly to repeat the process after lunch, so we didn't.

Priority 7: The banquet: a formal dinner (sit-down) freezes you
into conversation with the same few people all evening.  We
would prefer a buffet style meal to permit circulation.  There
also seemed to be too many students and too few TEK people;
a ratio of about 1.5 / 1 (Student/TEK) seems about right.  On
the very first banquet, TEK folk outnumbered students, and that
was bad; also, although buffet it was a pot-luck which we
certainly wouldn't want to do again (too unprofessional).
We liked the privacy of the dining room; that kind of isolation
should be provided next time, too, though the poshness of the
restaurant need not be preserved if the number of people increase.

Well, there it all is.  There are no priority 9-10 items (we
never just make passing suggestions!) after all.  If we are
told about future decisions and policies, we'll be happy to
comment on them.  There are four people in the company who
have had experience teaching AI courses at Stanford and
MIT: Ed, Doug, Randy, and Mike (in roughly decreasing order
of experience); those are the people who Teknowledge should
involve in setting up modular TUTs, Lisp courses, etc.
We were quite surprised that we were not in on the initial
design of the tutorials; our recommendations to modularize
the curriculum and think twice about EMYCIN/AGE/et al marketing
(and TUT3's to train for using them) fell on deaf ears at
the time.  We hope the above comments don't likewise get
filed away with no action taken.  TUT-I can and should be
more enjoyable for both the students and for us; a relatively
small effort in the next four months (starting now, not
in September) can make it so.

Regards,
Doug & Randy